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I introduction: 

One of the complaints about DTS 2000 is tliat it is difficuit to depioy pacl<ages. Specifically related to this 
document, it Is difficult to move a package from one machine to another. We need to provide a better way to 
move packages to other machines. The aim of this document is to describe the deployment architecture for 
DTS Yukon and how to use It. 

This Is a proposed solution and Is an early draft. Your input is encouraged. 

I Generai goals: 

The general deployment goals are: 

1 . Enable simple deployment of packages or data from one machine to another. 

2. Enable deployment either through SQL Server or through a bundled deployment file. 

3. IVIake the deployment process transparent to the user. 

4. Deployment should be extensible to allow third parties to participate. 

5. Deployment should be configurable, i.e. allow for parameters. 

6. Deployment bundles should be self installing and require very little if any interaction with the user. 

I Scenarios: 

Deploying a package with a Deployment Bundle 

I have a package that uses the pipeline and a custom task that I created. I need to move the package to a new 
machine that has never had my custom task installed on it. I go to the machine where the package was 
Installed and open the package that I want to deploy. I select the deploy menu Item and a dialog box pops up 
with some options for deploying the package. Since the target machine has never had my custom task Installed 
on it, I tell the deployment wizard which dependent tasks to include in the package. After I set the options I click 
OK. One of the options was the name of the deployment bundle I wish to create. When the deployment is 
complete, I go to the folder I specified and I see that the deployment bundle is there. I copy the deployment 
bundle over to the target machine. On the target machine, I right click the deployment bundle and click "Install". 
Then I open up the DTS Designer, open the deployed package and run it without errors. 



Deploying a package through SQL Server 

The scenario is the same, except I want to deploy everything through SQL Server. 

[How is this different? Do we want to create a bundle and store it in binary form in the server? Do we just 

deploy the package through a remote insert and bundle the rest into a deployment file?] 

I The Five Leveis of Deployment 

None 

None is what we have today. Essentially, the user copies the package file and hopes for the best. However, 
we should be even better with error reporting that indicates what package dependencies are missing. 

Minimal 

Minimal involves copying the package and a configuration file. 
Partial 

Partial includes a minimal bundle with the binaries for tasks that are 



Microsoft Confidential 



Page 3 



DTS Deployment 



Full 

A full deployment bundle combines a partial bundle with the redistributable portions of the runtime. This would 
make it possible for a fully bundled package to be deployed to a machine with no DTS installation and run with 
no errors* 

Data 

A data bundle is a combination of any of the above bundles with other items also bundled such as SQL objects 
or tables. 

* - Assuming no dependencies outside of DTS. 



I The Details 

Ideas on how we would accomplish this. 

For full deployment, we would leverage the work the setup folks are doing. There would need to be a well 
known location for the DTS redistributables that deployment would bundle with packages. There needs to be 
some thought put into how the runtime redistributables are factored and how the bundling of binaries is done. 

• Do we always bundle the whole runtime? 

• Do we only bundle what the user requests? 

• For partial deployments do we bundle internal tasks if they are in the package or are these user 
settings? 

• Can full deployment bundles be deployed through SQL Server? 



Tasks can describe their dependencies through a property called "Dependencies". When deploying, the 
package enumerates all the tasks and interrogates this property. If the task is "marked" by the user for 
deployment, the package uses this property to discover dependencies needed to be bundled for that task. 

Bundles are built using MSI files. 

I Cookbook 



I Open Issues 

Who is doing what? 

Bundling - Aqueduct Runtime Team? 
Wizard - Picasso Designer Team? 
Data bundling - Komodo Team? 

The details need to be worked out. 

"Voodoo doll" Jim wants to include signed and clear text features as well as the notion of a verify only 
deployment. 
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